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Abstract. The Input/Output (I/O) automaton model, developed by 
Lynch and Tuttle[ll], models components in asynchronous concurrent 
systems as labeled transition systems. IOA is a precise language for de- 
scribing I/O automata and for stating their properties. A toolset is being 
developed for IOA, to support distributed software design and implemen- 
tation. One of the tools consists of a user-assisted code generator from 
IOA into an imperative programming language such as C or Java. 
One aspect that distinguishes IOA programs from programs written in 
imperative languages, is the presence of nondeterminism, which comes 
in the form of explicit nondeterministic statements and implicit schedul- 
ing choices made during execution. Code generation therefore consists 
partially of systematically removing all forms of nondeterminism. 
In this paper, we describe our approach and design for code generation. 
We focus on the issue of removing implicit nondeterminism, and spec- 
ify a transformation on IOA programs that makes all nondeterminism 
explicit. The programmer can then replace all explicit nondeterminism 
with deterministic statements, prior to code generation. We also describe 
this transformation at a semantic level, i.e., at the level of the I/O au- 
tomaton mathematical model. We show that the transformation defined 
at the IOA level conforms to the one at the semantic level. 



1 Introduction 

The Input/Output (I/O) automaton model, developed by Lynch and Tuttle [11], 
models components in asynchronous concurrent systems as labeled transition 
systems. It has been used to model and verify many distributed algorithms and 
distributed system designs, and also to express impossibility results. Lynch's 
book Distributed Algorithms [9] describes many algorithms in terms of I/O au- 
tomata and contains proofs of various properties of these algorithms. In [10], 
the authors describe atomic transactions in terms of I/O automata. Examples of 
work done using this model include among others, implementation of sequentially 
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consistent shared objects [3], group communication systems [4, 2], verification of 
communication protocols [14]. 

10 A is a precise language for describing I/O automata and for stating their 
properties. It uses Larch [7] specifications to define the semantics of abstract 
data types and I/O automata. A toolset is being developed for IOA, to support 
distributed software design and implementation. These tools range from light 
weight tools, which check the syntax of automaton descriptions, to medium 
weight tools, which simulate the action of an automaton, and to heavier weight 
tools (e.g., theorem provers), which provide support for proving properties of 
automata. 

The toolset design includes a user-assisted code generator from IOA into 
an imperative programming language such as C or Java. The goal of the pro- 
cess is to produce a collection of programs that runs in a physically-distributed 
setting and whose correctness has been proved, subject to stated assumptions 
about the behavior of externally provided system services (e.g., communication 
services), and subject to assumptions about the correctness of hand-coded data 
type implementations. 

One aspect that distinguishes IOA programs from programs written in an 
imperative language is the presence of nondeterminism, which comes in the form 
of explicit nondeterministic statements and implicit scheduling choices made 
during execution. Code generation therefore consists partially of systematically 
removing all forms of nondeterminism. This consists of removing all instances of 
implicit nondeterminism, and making them explicit statements, and having the 
user replace all explicit nondeterminism with deterministic statements. 

In this paper, we review our approach and design for code generation, and 
the various transformations involved in it. We then carefully focus on one such 
transformation which makes the implicit nondeterminism explicit. We describe 
this at the level of IOA programs, and call it the syntactic NAD 1 transformation, 
as well as at the level of the I/O automaton model which we call the semantic 
NAD transformation. The motivation for the latter is to provide a more general 
framework for describing the transformation and present it in its full generality, 
unconstrained by program syntax. We also use the semantic NAD transformation 
to prove that our syntactic transformation is "correct," and conforms to it, in a 
sense we define in a later section. 

The outline of the paper is as follows. Section 2 briefly reviews the I/O au- 
tomaton model and the IOA language. Section 3 describes the code generation 
process within the IOA toolset. Section 4 presents the syntactic NAD transfor- 
mation on IOA programs, and Section 5 the semantic NAD transformation on 
I/O automata. Finally, Section 6 gives a summary and explores directions for 
future work. 



NAD stands for next-action deterministic, and will be introduced shortly. 



2 Background 

2.1 I/O Automata 

An I/O Automaton A is a tuple consisting of the following components 2 . 

— Sig(.4): a signature, consisting of three disjoint sets of input actions IN4, 
internal actions lNT.4, and output actions O1JT.4. We use All^ to denote 
the set of all actions of A, and L0C.4 denotes INT4 U Out^. 

— States(^I): a set of states. 

— StateSo(-4): a nonempty subset of States(^I) known as the initial states. 

— Trans(^I): a state-transition relation, where Trans(^I) C States(^I) x 
All_4 x States(^I), and for every state S and every input action ir, (S, ir, 
S') G Trans(71). 

Note that every input action is enabled in every state; we say that I/O 
automata are non blocking on inputs. An execution fragment of A is a sequence 
of states and actions, <So, ttq, <Si, tt\, ■ ■ ■ , starting at a state and such that (Si, 
■Ki, <Sj+i) £ Trans(^I). An execution of A is an execution fragment starting at 
a start state. A trace of A is the subsequence of an execution of A consisting of 
all input and output actions. We use Traces(A) to denote the set of traces of 
A. 

We now introduce what it means for an automaton to be next-state deter- 
ministic, and next-action deterministic. 

Definition 1. An I/O automaton A is next-state deterministic if there is a 
unique initial state and, for all S € States(^I) and for all ir € Ali^ there is at 
most one S 1 s.t. (S, ir, S 1 ) G Trans(,4). 

Definition 2. An I/O automaton A is next-action deterministic if for all S € 
States(^I), there is at most one ir € L0C.4 enabled in S. 

Most I/O automata that are written are not next-action deterministic. They 
have a form of implicit nondeterminism, which consists of nondeterministically 
choosing the next enabled action to execute. Transforming an I/O automaton 
into a next-action deterministic one, is a step in generating code from it. 

2.2 IO A Language 

10 A is a precise language for describing I/O automata and for stating their 
properties. It uses Larch [7] specifications to define the semantics of abstract 
data types. An IOA program A contains the following syntactic components. 

— Pararcu, contains the parameters to the IOA program A. 

— Larch a, contains the Larch traits used or assumed by A. 



We omit tasks for the purposes of this paper. 



— Act a, contains the actions of A, where each action a is of the form: 
Kind a a(pi : Pi, ■ ■ ■ ,p n : P n ) where pred a , 

where Kind a is either input, output, or internal. 

— Var^, contains the state variables of A together with their types. 

— initA, denotes the initial condition of A. 

— Tc\a, contains the transition definitions of A, where each transition definition 
d corresponding to an action named a is of the form: 

Kind a a(h , ■ ■ ■ , t n ) where predd 
choose psd 
pre pre d 
ef f progd 

so that soThatd 

The transition definition above specifies a transition for action a having parame- 
ters (*i, ■ ■ ■ ,t„) subject to the predicate predd- The keyword choose introduces 
parameters used in the body of the transition definition that are chosen non- 
deterministically. The keyword pre introduced the precondition, and ef f a se- 
quence of statements representing the effect of the action on the state. Finally, 
the so that predicate puts additional constraints on the effect. 

An example of an 10 A program is given in Figure 1, which represents a 
process in the LeLann-Chang-Roberts (LCR) leader election algorithm. In this 
algorithm, a finite set of processes arranged in a ring elect a leader by commu- 
nicating asynchronously. The algorithm works as follows. Each process sends a 
unique string representing its name, which need not have any special relation 
to its index, to its neighbor. When a process receives a name, it compares it to 
its own. If the received name is greater than its own in lexicographic order, the 
process transmits the received name to the right; otherwise the process discards 
it. If a process receives its own name, that name must have travelled all the way 
around the ring, and the process can declare itself the leader. Here we do not 
show the channel automata that must be composed with the processes. 

Note that in this example, all the parameters of transition definitions are 
globally unique. This is not a requirement of IOA programs. However, it is 
an assumption that we make, without loss of generality, on the form of IOA 
programs that are subjected to the NAD transformation. 

3 Code generation using the IOA Toolset 

The code generation tool currently under development is designed to translate 
IOA programs into executable programs written in a standard imperative lan- 
guage. The programmer starts with a distributed algorithm expressed in IOA 
and uses the tool to produce executable code that runs in a physically distributed 
computational environment. In our current target environment, the resulting col- 
lection of programs runs on a collection of networked workstations. Each host 
runs a Java interpreter and communicates via (a subset of) the Message Passing 
Interface (MPI) [5, 1] or TCP/IP [8]. This collection can be proved equivalent 



automaton Process (I: type, i: I) 
assumes Ringlndexd, String) 

type Status = enumeration of waiting, elected, announced 
signature 

input receive(m: String, const left(i), const i) 
output send(m: String, const i, const right(i)), 
leader (m: String, const i) 
states 

pending: Mset [String] := {name(i)}, 
status: Status := waiting 
transitions 

input receive (ml, jl, il) 

eff if m > named) then pending := insert (m, pending) 
elseif m = name(i) then status := elected 
fi 
output send(m2, i2, j2) 
pre m € pending 

eff pending := delete (m, pending) 
output leader (m3, i3) 

pre status = elected A m = name(i) 
eff status : = announced 



Fig. 1. IOA specification of election process 



to the original algorithm, subject to stated assumptions about the behavior of 
externally provided system services (e.g., communication services), and subject 
to assumptions about the correctness of hand-coded data type implementations. 



3.1 Approach 

To transform the original expression of the algorithm in IOA into an executable, 
the programmer is guided through a series of successive refinements to create 
an equivalent form of the program that is suitable for automated translation. 
Generally, the programmer begins with a simple, global description of the be- 
havior of the system and its interface to the environment. This high-level model 
tends to be easy to understand and to have important global properties that 
can be proved. The refined, low-level version of the program is a collection of 
interacting automata whose form corresponds to the distributed nature of the 
target environment while preserving the important properties and interface of 
the system. The programmer can use the validation tools included in the toolset 
to confirm the correctness of these refinements. 

The code generation process starts with an automaton designed to run on 
a single computational node of the distributed system. To generate code for an 
entire system, this process is repeated for each algorithmically distinct node. For 
example, the programs implementing clients and servers are likely to be compiled 



separately but the code for parameterized clients or peers can be compiled just 
once. 

The process consists of a series of refinements of that "algorithm" automa- 
ton. The automaton is connected to (models of) external system services and 
transformed to eliminate implicit nondeterminism. The resulting IOA program 
can then be automatically translated into the target imperative language and 
linked to libraries that implement the external system services. 

The code generator is structured as a set of small modules, each of which 
performs a transformation. Transformations are source-to-source within the IOA 
language (or in an internal intermediate form) up to the last step. Only in 
that last step is the IOA program translated into the target language. In our 
prototype, we have implemented a unified graphical user interface (GUI) to guide 
the programmer through this process. 

The code generator does not generate code for the entire distributed system. 
Rather, it generates the specialized code necessary to implement the algorithm at 
each node. As with any programming system, newly written programs leverage 
preexisting, external system services. Programs connect to those services when 
running. 

For each external system service, we design at least two models. First, we 
write an abstract model that describes the interface and the behavior of the 
service that the IOA programmer wants to use (e.g., point-to-point, reliable, 
FIFO channels as in [9], Chapter 8). Second, we write a lower-level concrete model 
that corresponds to the interface and behavior of the actual preexisting service 
(e.g., MPI [15]). We then introduce one or more auxiliary automata, written 
in IOA, that compose with the lower-level model to implement the abstract 
service. (See Fig. 2). Interfaces to system services may be fixed or algorithmically 
described. In the former case, the auxiliary automata are fixed and kept as a 
library. In the latter case, the auxiliary automata must be generated for each 
program. To create a complete executable for each node, the code generator 
actually emits code for the composition of the algorithm automaton and all the 
auxiliary IOA automata for all the system services the algorithm accesses. 
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Fig. 2. Auxiliary automata mediate between external system services and algorithm 
automata 



There is a once-per-service proof obligation that the composition of the con- 
crete model and the auxiliary automata implements the abstract service. Once 
the proof is done, the programmer can use the properties of the abstract model 
subject to the assumption that concrete model corresponds to the behavior of 
the service. For example, a proof of correctness for our design that uses MPI to 
implement reliable FIFO channels appears in [15]. 

Each external system service introduces constraints on the form of the low- 
level IOA program that accesses it. For example, since the code generator uses 
standard workstation networking services, programs submitted for code gener- 
ation are required to be in node-channel form. That is, the algorithm must be 
described as a collection of algorithm automata (one per node) that communicate 
via standard, one-way, reliable, FIFO channel automata. 

In addition, the model introduces another (technical) constraint. Atomicity 
requires that the effect part of each transition be done without interruption, 
even if inputs arrive from the external user or from the communication service 
during its execution. In our design, such inputs are buffered. In between running 
non-input actions, the generated program examines buffers for newly arrived 
inputs, and handles (some of) them by running code for input actions. Since 
the processing of inputs is delayed (with respect to the performance of these 
actions by their originators), such delays have the potential to upset precise 
implementation claims for the algorithm automata. We call this the input delay 
insensitivity assumption. 

By insisting that IOA programs from which we generate real code match 
the available hardware and services, and by requiring algorithm automata to 
tolerate input delays, we avoid the need for expensive non-local synchronization 
in achieving a faithful implementation. 

3.2 Design 

The code generator consists of a series small program transformers. Each accepts 
an IOA program or programs as input and produces another IOA program as 
output (except the last, of course, which translates IOA into the target language). 
Several of the modules are used by some, if not all, other tools in the IOA 
toolkit. The granularity of the transformation is driven largely by the usefulness 
of mixing and matching these tools. Table 1 lists the steps in the process. Below, 
we describe each step in process. We briefly sketch the function of each module 
and show how it is used in the code generation process. 

The first module to which any IOA program is submitted is the parser and 
static semantic checker (or simply checker). In addition, to the obvious func- 
tions, the checker produces an intermediate representation suitable for use by 
other tools. This S-expression-based intermediate language (IL) has a simpler 
parse tree than the more readable IOA source language. [12]. As the checker acts 
as a front-end to just about all other elements of the toolset, the IL provides 
a convenient interchange language within the IOA toolset. A checker prototype 
has been implemented. The IL representation is semantically equivalent to the 
source representation. 



Table 1. Transformers in the IOA code generation process. Numbers in the input 
column indicate that the transformer takes in the output of the numbered step. 
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The interface generator connects an algorithm automaton with the external 
console system service. The console service embodies all user interaction with an 
IOA program at a particular node. The interface generator creates a customized 
auxiliary automaton to mediate between the console service and the algorithm 
automaton. The auxiliary console automaton parses input from the console into 
input actions for the algorithm automaton. Similarly, output from the algorithm 
automaton is forwarded to the console. In our initial prototype the abstract 
model of user input allows the user to nondeterministically invoke any (non- 
network) input of the algorithm while the concrete model of the console is a 
simple source and sink for streams of integers [16, 13]. 

The composition tool (composer) converts the description of a composite au- 
tomaton into primitive form by explicitly representing its actions, states, tran- 
sitions, and tasks. The IOA language includes a composed of statement which 
defines an automaton to be the parallel composition of referenced automata. The 
composer expands the composition statement by "instantiating" and combining 
the referenced automata as described by the logical operation on the model. In 
the resulting description, the name of a state variable is distinguished by the 
names of the components from which it arises. The input to the composer must 
be a compatible collection of automata; for example, the component automata 
should have no common output actions. Note that composition is a semantically 
"neutral" operation. That is, the I/O automata described by the input program 
using the composed of statement is equivalent to that described by primitive 
output program. 

In the code generation process, the programmer's original algorithm automa- 
ton is composed with the the auxiliary interface automaton (generated in the 
previous step) with fixed auxiliary network automata. The resulting automaton 
describes all the behavior of the executable code we actually wish to generate 
for that node. Unfortunately, it is not obvious how to directly translate this 
nondeterministic form of the program into a standard imperative language. 

The next-action determinator (NAD) converts the input IOA program into 
an equivalent (in the sense of trace inclusion) next-action deterministic program. 
The NAD form of an IOA program has no implicit nondeterminism. Explicit 



nondeterminism is grouped in a new schedule transition that contains one set of 
choose statements. In this stylized form, each nondeterministic choice is assigned 
directly to a state variable of the automaton. Section 4 details the actual program 
transformation. Section 5 shows equivalence of the input and output programs. 

The final step before actually emitting imperative code is to remove explicit 
nondeterminism from the automaton. The resulting program is both next-action 
and next-state deterministic. In our prototype, the graphical user interface con- 
verts the NAD form from the intermediate language into IOA source to display 
to the programmer. The programmer edits the schedule transition by replacing 
each choose expression in turn with a deterministic IOA expression that selects 
a value from the same set as the choose expression. Showing this is a proof 
obligation for correctness. The resulting IOA node automaton is completely de- 
terministic and easily translated into an imperative language. 

The code emitter module translates one primitive, deterministic, node au- 
tomaton into actual code in the target language that implements the node au- 
tomaton, in the sense of trace inclusion. For each operation, we emit code from 
class libraries written in a standard programming language (currently, Java). 
At present, we do not address the problem of establishing the correctness of 
this sequential code (other than by conventional testing and code inspection). 
Standard techniques of sequential program verification based, for example, on 
Hoare logic, should be capable of handling such correctness proofs. (Note that 
the IOA framework focuses on correctness of the concurrent, interactive aspects 
of programs rather than of the sequential aspects.) 

Since all implicit nondeterminism has been removed, the code emitter can 
start from the unique initial state and perform a loop in which, at each iteration, 
it executes the unique action enabled in the current state. More specifically, it 
uses the programmer-provided expressions to determine the next transition and 
parameter values and then executes that transition with those parameters. Since 
there is no explicit nondeterminism, this uniquely determines the next state. 

4 Syntactic NAD Transformation 

In this section, we describe the syntactic NAD transformation on IOA programs, 
which makes implicit nondeterminism explicit. Then in the next section, we 
present the transformation in the I/O automaton model and show that the 
syntactic transformation conforms to the semantic one in a precise sense. 

We first introduce some notation. Let t be a term and i a sequence of terms. 
Let v and x be sequences of variable names, having the same size as t. We write 
t[v | t\ to denote a term identical to t where every free occurrence of Vi, i > 1, if 
any, has been replaced by i,. We write v = x to denote f\ t Vi = Xi. 

In the program we intend to transform, we assume that the free variables of 
actual parameters for transition definitions and choose parameters are unique 
throughout the program 3 . 



3 This assumption does not cause loss of generality. It is possible to relax it by first 
performing some renaming on the program to be transformed. 



Given an IOA program A, let B be the following program, with actions Acts, 
state variables Var#, initial condition Inits, and transition definitions Td^. 

— Paramo is identical to Pararcu. 

— Larch # is identical to Larch^. 

— Acts is identical to Act^, with an additional internal action: 
internal Sched 

— In addition to the state variables of A, Var# has the following state variables. 

• w\ : W\, ■ ■ ■ , Wk ■ Wk, where w\ through wu are the free variables ap- 
pearing in actual or choose parameters of locally controlled actions of 
A. 

• pc : {d\, • • • , d m , sched}, where d\ through d m are the locally controlled 
transition definitions of A in the order that they appear syntactically. 

— Inits is InitA Apc = sched. 

— Tds consists of the following. 

• For each input transition definition d of A, Td# contains an identical 
transition definition d' having effect 

P ro 9d\ pc = sched. 

• For each locally controlled transition definition d of A, corresponding to 
an action named a, Td^ contains the following transition definition d' , 
where Wd denotes the sequence of free variables appearing in actual or 
choose parameters of d, and a; is a sequence of fresh variables having the 
same size as Wd- 

Kind a a(ti[w d | x], ■ ■ ■ ,t n [w d \ x\) 
pre pc = d AtVd = x 
eft prog d ; 

pc := sched 

so that soThatd 

• The following transition definition for the internal action Sched, where 
a\ , • • • , a m are the corresponding action names of d\ , • • • , d m , and p ai 
and idi, 1 < i < m, are the sequence of formal parameters of action a,, 
and actual parameters of transition definition di , respectively, 
internal Sched 

pre pc = sched 
ef f w\ := choose; 

w„ := choose; 

pc := choose q where q ^ sched; 

if -i(pc = di A pre dl A where ai [p ai | i dl ] A where dl 

V ... 

V pc = d m A pre dm A where am [p am \ i dm ] A where dm ) 
then pc := sched f i 

We now consider again the example introduced in Section 2.2, representing 
a process in the LCR leader election algorithm. Figure 3 presents the result 
of subjecting that example automaton to the NAD transformation we defined 



above. The transformation adds an internal action, sched, as well as a state 
variable pc. It also adds all parameters of locally controlled actions to the state. 
The parameters of these actions are renamed, and the names do not have to be 
unique. The Sched action first chooses values for the parameters and for pc, and 
then checks whether an action is enabled given these values. If there is, then 
that action is chosen to be executed next. The precondition of locally controlled 
actions have been modified to make this possible. 

In this example, all nondeterminism is explicit in the form of choose state- 
ments which choose a value nondeterministically, subject to a condition specified 
after the keyword where 4 . Moreover, in any state there is at most one action 
enabled. We show that this automaton satisfies next-action determinism, more 
precisely in the next section. 

5 Semantic NAD Transformation!! 

In this section, we present the NAD transformation at the I/O automaton level, 
and refer to it as a semantic transformation. Our motivation is to provide a 
transformation at the level of the mathematical model as a complement to the 
syntactic one. This gives a more general characterization of the transformation, 
and provides a framework in which we can verify that the syntactic transforma- 
tion is correct. 

5.1 Semantic Transformation 

We define the semantic transformation by giving a relation NAD(.4), which 
denotes the set of all next-action deterministic I/O automata corresponding to 
A. 

The relation NAD (.4) is defined by giving restrictions on the components of 
the automata that belong to it. An automaton B in NAD (.4) has all the actions 
of A, and a set of additional internal actions, which we call scheduling actions, 
and denote II. 

Next we define the restrictions on the set of states of £>. We first define a 
partition V on the states of B, having an equivalence class for each action that is 
locally controlled in £>. We write V^ to denote the equivalence class corresponding 
to 7r. Informally, a state <S is in V„, if action 7r has been chosen for execution in 
state S. The action tt may or may not be enabled in S. 

We then define a second partition Q on the states of B, having an equiva- 
lence class for each state of A. We write Qs A to denote the equivalence class 
corresponding to the state <S^ of A. Informally, a state S of B is in Q s + , if it 
"corresponds" to S + . 

Having defined these two partitions we state that they must be restricted 
such that V<S G States(.4), tt G Loc b , QsPlPj ^ holds. This condition 
allows us to introduce the following notation. We write [ir,S] to denote Qsr\V n , 
and call it a sector. 



When the condition is omitted, it is simply true. 



automaton Process (I: type, i: I) 
assumes RingIndex(I, String) 

type Status = enumeration of waiting, elected, announced 
signature 

input receive(m: String, const left(i), const i) 
output send(m: String, const i, const right(i)), 

leader (m: String, const i) 
internal Sched 
states 

pending: Mset [String] := {name(i)}, 
status: Status := waiting, 
m2 , m3: String, 
i2, i3: I, 
j2: I, 

pc : enumeration of send, leader, sched 
so that pc := sched 
transitions 

input receive (ml, jl, il) 

eff if ml > name(il) then pending := insert (ml, pending) 
elseif ml = name(il) then status := elected 
H; 

pc := sched 
output send(m, i, j) 

pre pc = send Am = m2 Ai = i2Aj=j2 
eff pending := delete (m2, pending); 
pc := sched 
output leader (m, i) 

pre pc = leader A m = m3 A i = i3 
eff status : = announced 
internal Sched 
pre pc = sched 
eff m2 := choose; m3 := choose; 

i2 := choose; i3 := choose; j2 := choose; 
pc = choose q where q ^ sched; 
if not (pc = send A m2 £ pending 

V pc = leader A status = elected A m3 = name(i3)) 
then pc := sched fi 



Fig. 3. IOA specification of election process 



Informally, B is an automaton which behaves like A, but in addition it ex- 
plicitely chooses which action to execute next. For each state Sa of A, B has a 
set of states corresponding to <S^, and these states encode different choices for 
the next action to execute. A state in sector [ir,S] corresponds to state S of A 
with the choice of executing action 7r next. 

It remains to specify the initial states of B, as well as its transitions. The 
initial states of B are all those that belong to [7r,<So], for 7r € i7 and <So is an 
initial state of A. 

The transitions of B must be such that if B goes from state S to state S 1 while 
executing action 7r of A, then S corresponds to state <S^ of A, S 1 corresponds to 
S' A , and (<S^,7r,<S^) is a transition of A. 

Figure 4 illustrates the execution of some automaton b € B. In this figure, 
rows represent partition V and columns partition Q. The states in equivalence 
classes of V corresponding to scheduling actions are labeled scheduling states. An 
execution of B starts at an initial state, which is a scheduling state corresponding 
to an initial state of A. Then B executes a scheduling action, and chooses an 
action to execute that is enabled in the current state. This causes the automaton 
to move vertically into a state in which a choice has been made. Next, B executes 
the chosen action, and moves to a scheduling state, and this process is repeated. 
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Fig. 4. The exectution of some automaton b 6 B. 



Formally, the Nad relation is given as follows. 



Definition 3. B G NAD (.4) if and only if these exists a set U of actions disjoint 
from All_4, and partitions V and Q on States(£>), having an equivalence class 
for each action in LoCg and each state of A, respectively, such that: 

1. VS e States(.4), tt g Loc b , Q s n V* ^ 0. 

2. SlG(B) = (1N4, Int^ U 77, OUT4). 

5. StateSo(-B) = {«S | 3tt G 77,<S G States (.4),<S G [7r,<S ]}. 
4- A transition (S,ir,S') is in Trans(£>) if and only if: 

37T G 77,5,4,5^ G States(^I) such that: 
7T G lN^A(«S^,7T,«S^) G Trans(^I) A S G Q Sa A S' G [7T ,«S^] 
V 

tt G Loc^A(<S^,7r,<S^) G Trans(^I) ASg [tt,S a ] AS' G [tto,«S^] 
V 

7TG77A5G [7r,^]A«S' G [ttq,^] U [tt',S a }, 
for tt' G L0C.4 such that tt' is enabled in Sa- 

5.2 Soundness of Semantic Transformation 

In this section, we argue that any I/O automaton in NAD (.4) has the same 
traces as A and satisfies next-action determinism. 

Lemma 1. Let B G NAD(y4). Then Traces(K) = Traces(.4). 

Proof. We do not show the proof here. This can be done by induction on the 
length of an execution [17]. 

Lemma 2. Let B G NAD(.4). B is next-action deterministic. 

Proof. Let S be a state of B. In order for any locally controlled action tt of B 
to be enabled in S, S must be such that S G V n , by construction. Since V is 
a partition on States(£>), then there is at most one locally controlled action 
enabled in S. Thus B is next-action deterministic. 



5.3 Correspondence Between the Syntactic and the Semantic 
Transformations 

In this section, we argue that the syntactic transformation described previously, 
conforms to the semantic transformation above. For this we introduce the notion 
of the semantic of an IOA program sem. For an IOA program A, sem(A) denotes 
the I/O automaton corresponding to A. The semantics of IOA programs have 
been defined precisely in [6], and we will not reproduce them here. 

Let B be the result of transforming IOA program A with the NAD syntactic 
transformation. Then the following holds. 

Theorem 1. sem(B) G NAD(sem(^)) 



We do not show the formal proof here, since that would require showing as 
well the precise definition of the semantics of a program, but we give the informal 
argument behind the proof. The proof is presented in [17]. 

In order for sem(B) to be related to sem(A) via the semantic NAD transfor- 
mation, there must exist a set II of actions and partitions V and Q satisfying 
the conditions of Definition 3. In this case, II consists of a single action Sched. 

The state of B consists of all the states of A and some additional state 
variables, pc and parameter lists, that indicate which action to execute next. We 
specify the partition Q as follows. A state S of B is in Qs A , for a state Sa of A, 
if the portion of state S corresponding to the state of A, is identical to <S^. 

We specify the partition V as follows. A state S of B is in V n , for a locally 
controlled action of B, if the extra state of S indicates that 7r is the next action 
to run. 

Given these values for i7, Q, and V, we can verify that the conditions of 
Definition 3 are satisfied. 

6 Conclusion 

In this paper, we presented our approach and design for code generation in I/O 
automata. We have also presented in detail, one of the transformation involved 
in this process, the syntactic NAD transformation (synNAD). Further, we de- 
scribed the transformation at the level of the mathematical model, the semantic 
NAD transformation (semNAD), and showed that the syntactic transformation 
conforms to it in a precise sense. 

The introduction of a semantic transformation illustrates a method for de- 
signing program transformations in this context. We use semNAD as a "specifi- 
cation" transformation, that is "implemented" by synNAD. Our method consists 
of giving a semantic transformation and a syntactic one, and proving that the 
latter conforms to the former in a precise sense. This method has the following 
advantages. 

— A precise description of the transformation is given, which makes mathe- 
matical manipulation possible. 

— The definition of the transformation is as general as possible. 

— It is not tied down to a particular language syntax. 

— Syntactic variations of the same transformation can be easily shown to be 
equivalent. 

As future work, we plan to investigate ways of assisting the user in replacing 
explicit nondeterministic statements with deterministic ones, and to complete a 
working prototype of the code generator. 
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